gh-158973: Reset the warnings lock after fork in the child - #158974

I was able to reproduce this independently and validate the fix.

With a probe similar to test_fork_other_thread_holds_lock (a worker holds the warnings lock and keeps an object with a warning-emitting finalizer in thread-local storage, then the main thread forks), the child hangs inside os.fork() in every attempt on main before this PR. It stays stuck until it's killed, even with a 10 s timeout. With this PR, the child runs the finalizer, writes its marker and exits with status 0 every time, and the parent's worker releases the lock and joins cleanly.

I saw the same on AWS Lambda (x86_64, PGO+LTO build), where this matters since the default runtime is a regular GIL build: every attempt hit the watchdog before the fix, and none did after it. test_warnings, test_fork1 and test_os pass with the change. Thanks for fixing this!

I think it's safe to store the bool in a static global: https://github.com/nascheme/cpython/compare/gh-158973-reset-warnings-lock...ngoldbaum:cpython:gh-158973-reset-warnings-lock?expand=1

This is being maximally cautions about avoiding ABI changes where they're not needed. I'm not sure if it's actually a problem in-practice. The static global is a bit of a code smell.

Thanks @nascheme for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15.
🐍🍒⛏🤖

Sorry, @nascheme, I could not cleanly backport this to 3.14 due to a conflict.

Please backport manually with cherry_picker, see the devguide for more information.

cherry_picker 801377967fd7bfa573c0b4c48e31b69d50c1da2f 3.14

GH-159613 is a backport of this pull request to the 3.15 branch.

GH-159614 is a backport of this pull request to the 3.15 branch.

GH-159615 is a backport of this pull request to the 3.14 branch.